Live MQTT-kontroll

tips

Live MQTT-kontrollen är avsedd för live-kontroll. För att skicka scheman i förväg, se Schemalagd MQTT-kontroll istället.

Denna guide hjälper dig att konfigurera MQTT på din Sofar EMS för att fjärrstyra och övervaka batteri- och solpanelsinstallationer.

Vad du behöver

1. Sofar EMS med internetanslutning.
2. MQTT-uppgifter: Detta kan begäras genom att skicka ett mejl till support@eniris.be.
3. Python-utvecklingsmiljö (eller vilken annan MQTT-klient som helst). Denna guide använder ett grundläggande exempel skrivet i Python för att få dig att komma igång med MQTT och skicka kommandon. Vi rekommenderar att använda Python för enkelhetens skull, men alla andra MQTT-klienter stöds.

Ytterligare information

MQTT är ett snabbt kommunikationsprotokoll över internet. Det är ett publicera/prenumerera meddelandesystem, som möjliggör en direkt förbindelse mellan din maskin och Sofar EMS. Dina tillgångar klassificeras i grupper för sol, batteri, EV och HVAC.

Första konfiguration (Utgångspunkt för nya användare)

Jag har en Sofar EMS som jag vill ställa in för MQTT-fjärrkontroll.

1. Kontrollera ditt nätverk

Säkerställ att ditt nätverk tillåter MQTT-nätverkstrafik över port 1883. Du kan göra detta med kommandot:

nc -zv mqtt.eniris.be 1883

När detta kommando inte är tillgängligt kan du alternativt ladda ner och köra denna python-kod.

När du är osäker, konsultera din nätverksingenjör eller använd temporärt din telefons 4G/5G-hotspot när anslutningsfel uppstår.

anteckning

När port 1883 inte är tillgänglig från ditt nätverk erbjuder vi en backup på port 80. Detta kan konfigureras i din MQTT-klient vid ett senare steg i denna manual.

2. Lägg till dina enheter

Logga in på commissioning-gränssnittet och se till att enheterna är tillagda till Sofar EMS.

3. Lägg till MQTT-externa signal

4. Aktivera MQTT-fjärrsignal

Fältet 'VPP ID' måste lämnas tomt.

Fallback-mekanismens timeout talar om för Sofar EMS hur länge den ska vänta på nya kommandon. När Sofar EMS slutar ta emot kommandon, går den automatiskt över till standardstrategin efter denna timeout.

Välj sedan alla enheter som du vill inkludera i MQTT-fjärrkontrollen.

5. Fjärrsignalen har lagts till

MQTT-fjärrkontrollgränssnittet har nu aktiverats på Sofar EMS.

Vi är nu redo att skicka några grundläggande kommandon med ett enkelt exempel. Statuskolumnen talar om huruvida något kommando är aktivt.

Python demo-skript

En bra första utgångspunkt skulle vara att testa din nyinställda integration med ett enkelt exempel.

Denna testkod gör en enkel uppgift genom att kontinuerligt skicka följande kommandon:

• Batteri: Ladda med 5 kW
• Sol: Ställ in effekten på 0 kW

Sofar EMS svarar kontinuerligt med ett 'feedback'-meddelande som innehåller de observerade nät- och tillgångseffektvärdena. Denna funktion ingår också i detta exempel.

Ladda ner filen nedan i din föredragna Python-IDE. Fyll i ditt serienummer och MQTT-uppgifter och kör skriptet:

När ovanstående är framgångsrikt kan du fortsätta med att skicka andra typer av kommandon. Alla kommandon beskrivs i vår MQTT-fjärrkontrolldokumentation.

MQTT-dokumentation för att skicka kommandon

Detta avsnitt detaljerar MQTT-meddelandets format och belastningskrav för fjärrstyrning av kraftpolicyer på enheter inom Sofar EMS's nätverk.

MQTT-ämne

MQTT-ämnet som används för att skicka kommandon är strukturerat som följer:

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Där 'controller SN' ska ersättas med det faktiska serienumret av den Sofar EMS som du avser att kontrollera.

MQTT-belastningsstruktur

Kommandon skickas som JSON-belastningar. Belastningsstrukturen är utformad för att specificera olika kraftförvaltningspolicys och inställningar för olika komponenter i det smarta elnätet. Här är översikten av belastningen med detaljerade fältsbeskrivningar:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "<Policy Type>",
        "<Component Power Setpoint>": <Setpoint in watts>
    }
}

Fältsbeskrivning

tips

Flera enhetstyper (t.ex. batterier + sol) kan kontrolleras samtidigt.

• extraTags (Objekt):
  • nodeId (Sträng): En unik identifierare för noden inom Sofar EMS's nätverk. Detta är lika med ditt serienummer, följt av '_site_0' för de flesta Sofar EMS-enheter.
• time (Heltal): Unix-timestamp i sekunder som anger tiden då meddelandet skickas.
• fields (Objekt):
  • <Component>_policy (Sträng): Policys typ för komponenten. Det är valfritt och om det inte anges kommer systemet att falla tillbaka till Sofar EMS's standardinställning.
  • <Component>_power_setpoint_w (Flyttal): Önskad effektinställning i watt för komponenten. Detta är valfritt och endast relevant om en motsvarande policy anges.

Komponenter och Policys

info

Tillgångar av samma typ (t.ex. två batterier) kommer att kombineras som en komponent. Till exempel, när två 5 kWh-batterier installeras, kommer det att betraktas som ett 10 kWh-batteri.

Varje komponent i fields-objektet kan inkludera en policy och en effektinställning. Följande komponenter kan kontrolleras:

• solar_policy och solar_power_setpoint_w:

  • Kontrollerar solkraftgenereringspolicy och inställning. Stödda policyer:
    • Policys inställning: Ställ in den maximala effekten som produceras av alla anslutna solinstallationer tillsammans. Fältet solar_power_setpoint_w bör ställas in på produktionskraftgränsen i watt.
    • Policy matningsbegränsning: Producerar med full effekt, i linje med aktuella nätgränser.
    • Policy kostnad: Aktiverar kostnadsminimering för dag-i-förväg pris (EPEX Spot marknad) på solproduktionen. När negativa injektionspriser förekommer, inskränker vi produktionen till eget konsumtion. När både uttags- och injektionspriserna är negativa, stänger vi av alla solinstallationer. Fältet solar_power_setpoint_w ignoreras.
    • Policy av: Inaktiverar all interaktion för alla soltillgångar. Varning: gränser skyddas inte i detta läge. Fältet solar_power_setpoint_w ignoreras.

• storage_policy och storage_power_setpoint_w:

• Styr energilagringssystemets policy och effektutladdnings- eller laddningshastighet.

  • Policynivå: Ställ in den totala laddningseffekten (positiv nivå) eller utladdningseffekten (negativ nivå) för gruppen av batterier. När flera batterier är anslutna delas nivån upp efter tillgänglig laddnings-/utladdningseffekt för att lika mycket belasta batterierna. Fältet storage_power_setpoint_w sätts till önskad batterikraft.
  • Policyn kostnad: Aktiverar daglig kostnadsoptimering (EPEX Spot-marknad) för batterierna, genom att ladda dem under billiga timmar och använda energin under dyra timmar. Fältet storage_power_setpoint_w ignoreras.
  • Policyn självförbrukning: Aktiverar en enkel självförbrukningsalgoritm för batterierna. Överskottsproduktion av solenergi lagras i batteriet under dagen, och när solen går ner tas energi från batteriet. Fältet storage_power_setpoint_w ignoreras.
  • Policyn av: Inaktiverar all interaktion för alla batteritillgångar. Varning: gränserna övervakas inte i detta läge. Fältet storage_power_setpoint_w ignoreras.

• heat_pump_policy:

  • Växlar på/av värmepumpsystem. Minimala och maximala påslagstider kommer alltid att respekteras.
    • Policyn kostnad: Aktiverar daglig kostnadsoptimering (EPEX Spot-marknad) för värmepumparna. Den lokala dynamiska prissättningsalgoritmen avgör de bästa påslagstiderna.
    • Policyn självförbrukning: Slår på värmepumparna om ett överskott av solenergi produceras.
    • Policyn power_off: Stänger av värmepumparna.
    • Policyn power_on: Slår på värmepumparna.

• switched_load_policy:

  • Växlar på/av relästyrda system. Detta kan vara det inbyggda reläet eller nätverksanslutna reläer.
    • Policyn kostnad: Aktiverar daglig kostnadsoptimering (EPEX Spot-marknad) för reläet.
    • Policyn självförbrukning: Slår på reläet om ett överskott av solenergi produceras.
    • Policyn power_off
    • Policyn power_on

• variable_power_load_policy och variable_power_load_power_setpoint_w:

  • Hanterar den elektriska fordonets energiförbrukningspolicy och nivå.
    • Policynivå: Ställ in den totala laddningseffekten för gruppen av elbilar. Fältet variable_power_load_power_setpoint_w sätts till önskad laddningseffekt.
    • Policyn kostnad: Aktiverar daglig kostnadsoptimering (EPEX Spot-marknad) för batterierna, genom att ladda dem under billiga timmar. Fältet variable_power_load_power_setpoint_w ignoreras.
    • Policyn självförbrukning: Aktiverar laddning om ett överskott av solenergi produceras. Fältet variable_power_load_power_setpoint_w ignoreras.
    • Policyn av: Inaktiverar all interaktion för alla elbilstillgångar. Fältet variable_power_load_power_setpoint_w ignoreras.

• site_policy och site_power_setpoint_w:

  • Hanterar platsens exportgränser.
    • Policyn export: Ställ in exportgränsen för platsen. Fältet site_power_setpoint_w sätts till exportgränsen.
    • Policyn standard: Återställer platsens gräns till den standardiserade exportkraften, som ställts in i kontrollerkonfigurationen.

Enhetskontroll

Specifika enheter kan också kontrolleras, istället för grupper av enheter baserat på deras typer. Meddelandet är identiskt strukturerat:

• nodeId_policy och nodeId_power_setpoint_w

info

När två kommandon skickas till samma tillgång (t.ex. ett enhetsspecifikt kommando till en solomvandlare och ett kommando till alla solenergi-enheter), kommer enhetsspecifik kontroll att ha företräde framför enhetstypkontroll.

Fallback-beteende

För varje komponent, om _policy och _power_setpoint_w inte specificeras, kommer systemet automatiskt att använda fallback-policyn som konfigureras i Sofar EMS. Detta säkerställer att varje enhet eller enhetsgrupp fungerar säkert och fortsätter att fungera även om specifika instruktioner inte ges.

Om inget kommando skickas alls, efter 60 sekunder (eller angiven timeout-period), kommer standardpolicyn för tillgångarna att återaktiveras.

Exempel på payload

Nedan är ett exempel på en payload för att ställa in olika policies och nivåer:

{
    "extraTags": {
        "nodeId": "OM12404080000000000_site_0"
    },
    "time": 1714652046,
    "fields": {
        "solar_policy": "setpoint",
        "solar_power_setpoint_w": 5000,
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": -5000
    }
}

I detta exempel är solkraften inställd på att generera upp till 5000 watt, och energilagringssystemet är inställt på att antingen ladda eller ladda ur med en hastighet av 5000 watt, beroende på tecknet i nivåvärdet. Om antingen solar_policy eller storage_policy utelämnades, skulle den respektive enheten återgå till standardinställningarna som bestämts av Sofar EMS.

MQTT-dokumentation för att ta emot feedback

Detta avsnitt beskriver strukturen och innehållet i feedbackmeddelandena som skickas av Sofar EMS via MQTT. Dessa meddelanden publiceras till ämnet standard1/outbound/remoteControlMetrics/feedback/<Controller SN> efter att ett kommando har behandlats.

MQTT Feedback-ämne

Feedback MQTT-ämnet är strukturerat som följer:

standard1/outbound/remoteControlMetrics/feedback/<Controller SN>

Där <Controller SN> bör ersättas med serienumret på Sofar EMS som skickar feedbacken.

Struktur för MQTT Feedback-Payload

anteckning

Alla tillgångar grupperas efter typ. Detta innebär att två individuella solinstallationer på 3 kW kommer att behandlas som en 6 kW tillgång.

Feedbackmeddelanden formateras som JSON-payloads. Dessa payloads ger detaljerad feedback om systemets tillstånd efter tillämpning av nivåkommandon, med hänsyn till nät-/enhetsgränser. Nedan är strukturen för feedback-payloaden med beskrivningar av dess fält:

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Grid Active Power in Watts>,
                "today_imported_energy_Wh": <Grid Imported Energy in Watt-hours>,
                "today_exported_energy_Wh": <Grid Exported Energy in Watt-hours>,
                "import_limit_W": <Grid Import Limit in Watts>,
                "export_limit_W": <Grid Export Limit in Watts>,
            },
            "vpp_id": "<Virtual Power Plant Identifier>",
            "storage": {
                "energy_stored_Wh": <Energy Stored in Watt-hours>,
                "energy_capacity_Wh": <Total Energy Capacity in Watt-hours>,
                "mean_soc_perc": <Mean State of Charge Percentage>,
                "active_power_W": <Active Power in Watts>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "executed_policy": <Policy Executed by the Controller>,
                "max_charge_power_W": <Maximum Charge Power in Watts>,
                "max_discharge_power_W": <Maximum Discharge Power in Watts>,
                "today_charged_Wh": <Energy Charged on the Current Today in Watt-hours>,
                "today_discharged_Wh": <Energy Discharged on the Current Today in Watt-hours>,
                "nr_devices": <Number of Controlled Storage Devices Installed>
            },
            "solar": {
                "active_power_W": <Solar Active Power in Watts>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "executed_policy": <Policy Executed by the Controller>,
                "capacity_W": <Solkapacitet i Watt>,
                "today_energy_Wh": <Energi producerad idag i Watt-timmar>.
                "nr_devices": <Antal installerade kontrollerade solapparater>
            },
            "heat_pump": {
                "executed_policy": <Policy utförd av kontrolleraren>,
                "operation_modes": <Värmepumps driftslägen>,
                "executed_power_W": <Effekt setpunkt skickad till apparater i Watt>,
                "nr_devices": <Antal installerade kontrollerade värmepumpsapparater>
            },
            "switched_load": {
                "executed_policy": <Policy utförd av kontrolleraren>,
                "devices_on": <Antal apparater påslagna>,
                "devices_off": <Antal apparater avstängda>,
                "executed_power_W": <Effekt setpunkt skickad till apparater i Watt>,
                "nr_devices": <Antal installerade kontrollerade lastapparater>  
            }
        },
        "response_code": <Svarskod>
    },
    "fields": {},
    "requestTime": "<Unix-tidsstämpel>",
    "time": "<Unix-tidsstämpel>",
    "siteNodeId": "<Controller SN>_site_0"
}

Fältbeskrivning

• time (Heltal): Unix-tidsstämpel som anger tiden då feedbackmeddelandet skickades.
• fields (Objekt):
  • state (Objekt):
    • vpp_id (Sträng): Identifierare för det virtuella kraftverket kopplat till denna enhet.
    • grid (Objekt):
      • active_power_W (Float): Representerar den aktuella aktiva effekten på elnätet i watt.
      • today_imported_energy_Wh (Float): Den totala energi som tagits från elnätet idag i wattimmar. Obs: Idag anges i UTC-tid.
      • today_exported_energy_Wh (Float): Den totala energi som injicerats tillbaka in i elnätet idag i wattimmar. Obs: Idag anges i UTC-tid.
      • import_limit_W (Float): Importgräns för elnätet i watt,
      • export_limit_W (Float): Exportgräns för elnätet i watt,
    • storage (Objekt):
      • energy_stored_Wh (Float): Aktuell mängd lagrad energi i watt-timmar.
      • energy_capacity_Wh (Float): Total energikapacitet för lagringssystemet i watt-timmar.
      • mean_soc_perc (Float): Laddningsstatus som en procent. Detta är det vägda genomsnittet bland alla anslutna batterier. (när flera batterier är anslutna: t.ex. batteri 'a' har en energikapacitet på 10 kWh och en laddningsstatus på 20%; batteri 'b' har en energikapacitet på 20 kWh och en laddningsstatus på 50%, då är mean_soc_perc 40%)
      • active_power_W (Float): Aktuell aktiv effekt för lagringssystemet i watt, som visar laddnings- eller urladdningshastighet.
      • max_charge_power_W (Float): Maximal effekt vid vilken lagringen kan laddas.
      • max_discharge_power_W (Float): Maximal effekt vid vilken lagringen kan urladdas.
      • executed_power_W (Float): Summan av den totala effekten som begärts för (urladdning) från lagringstillgångarna, som skickas ut av vår kontrollalgoritm. Endast tillämplig om 'follow_setpoint'-policy är aktiv.
      • executed_policy (Sträng): De policyer som har tillämpats på de kontrollerbara enheterna.
      • today_charged_Wh (Float): Den totala energi som laddats in i de kontrollerbara batteritillgångarna idag. Obs: Idag anges i UTC-tid.
      • today_discharged_Wh (Float): Den totala energi som urladdats från de kontrollerbara batteritillgångarna idag. Obs: Idag anges i UTC-tid.
      • nr_devices (Heltal): Antal kontrollerbara batteritillgångar.
    • solar (Objekt):
      • active_power_W (Float): Aktuell aktiv effekt som genereras av solpaneler i watt.
      • capacity_W (Float): Total kapacitet för solgeneratorn i watt.
      • executed_power_W (Float): Summan av den totala effekten som begärts från soltillgångarna, som skickas ut av vår kontrollalgoritm. Endast tillämplig om 'follow_setpoint'-policy är aktiv.
      • executed_policy (Sträng): De policyer som har tillämpats på de kontrollerbara enheterna.
      • today_energy_Wh (Float): Den totala energi som producerats från de kontrollerbara soltillgångarna idag. Obs: Idag anges i UTC-tid.
      • nr_devices (Heltal): Antal kontrollerbara soltillgångar.
    • heat_pump (Objekt):
      • executed_policy (Sträng): De policyer som har tillämpats på de kontrollerbara enheterna.
      • operation_modes (Sträng): Driftsläget för värmepumpen (Blockläge, Boostläge, Självkontrolläge)
      • executed_power_W (Float): Den förväntade effekt som den för närvarande använder.
      • nr_devices (Heltal): Antal kontrollerbara värmepumpar.
    • switched_load (Objekt):
      • executed_policy (Sträng): De policyer som har tillämpats på de kontrollerbara enheterna.
      • devices_on (Heltal): Antal apparater påslagna.
      • devices_off (Heltal): Antal apparater avstängda.
      • executed_power_W (Float): Effekten som den för närvarande använder (om tillgänglig).
      • nr_devices (Heltal): Antal kontrollerbara på/av-lastapparater.
    • nodeId (Objekt):
      • Om en nodeId ingår i kommandot kommer feedbacken att innehålla det motsvarande tillståndet för enheten.
  • response_code (Heltal):
    • Anger status för operationen. En response_code på 0 innebär vanligtvis framgång, medan andra värden kan indikera olika typer av fel eller statusinformation (dessa bör specificeras i en separat referens).

Exempel på feedbackpayload

Här är ett exempel på ett feedbackmeddelande efter ett kommando för att ställa in olika effekt setpunkter:

Denna feedback visar systemets aktuella driftsstatus efter genomförandet av setpunkterna, som indikerar effekterna på solgenerering, lagring och den övergripande interaktionen med elnätet.

Stödda MQTT-versioner och beteende vid obehöriga ämnen

Vid användning av MQTT är det viktigt att överväga skillnaderna i specifikationer mellan versionerna 3.1, 3.1.1 och 5.0, särskilt när det gäller mäklarens beteende när klienter publicerar till obehöriga ämnen.

Enligt MQTT 3.1.1-specifikationen (se OASIS MQTT 3.1.1-specifikation, sektion MQTT-3.3.5-2) måste en mäklare avsluta anslutningen så snart en klient skickar ett PUBLISH till ett ämne för vilket den inte har behörighet. Detta beteende kan leda till oväntade frånkopplingar för klienter som försöker publicera till felkonfigurerade eller obehöriga ämnen.

I MQTT 3.1 finns inte detta krav. När en klient publicerar till ett obehörigt ämne under denna version, ignorerar mäklaren vanligtvis meddelandet (tyst bortfall) utan att avsluta anslutningen. Detta gör MQTT 3.1 i vissa fall mer lämpligt när robusthet mot konfigurationsfel eller temporärt saknade behörigheter är viktigare än strikt säkerhetsförvaltning.

Även om MQTT 5.0 introducerar möjlighet att arbeta med orsakskoder (som PUBACK med en avvisningsorsak), kräver detta stöd på både klient- och serversidan. Migrering till MQTT 5.0 innebär därför ytterligare implementeringsinsatser.

Konsekvenser av att ignorera kompatibilitet: Om en klient ansluter med MQTT 3.1.1 och försöker publicera meddelanden till obehöriga ämnen, kommer mäklaren att abrupt avsluta sessionen. Detta kan leda till instabilitet, förlust av anslutning eller ökad belastning på grund av upprepade återanslutningsförsök.

Rekommenderad metod: För system där klienter kan (temporärt) försöka publicera till obehöriga ämnen, eller där felhantering inte är strikt implementerad, rekommenderar vi att använda MQTT 3.1. Detta säkerställer mer stabila anslutningar och undviker oavsiktliga avbrott under körning.